<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Section 10.8.&nbsp; Reliable-Signal Terminology and Semantics</title>
<link rel="STYLESHEET" type="text/css" href="images/style.css">
<link rel="STYLESHEET" type="text/css" href="images/docsafari.css">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/team.gif" width="60" height="17" border="0" align="absmiddle"  alt="Team BBL"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href=ch10lev1sec7.html><img src="images/prev.gif" width="60" height="17" border="0" align="absmiddle" alt="Previous Page"></a>
<a href=ch10lev1sec9.html><img src="images/next.gif" width="60" height="17" border="0" align="absmiddle" alt="Next Page"></a>
</div></td></tr></table>
<br><table width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td valign="top"><a name="ch10lev1sec8"></a>
<h3 class="docSection1Title">10.8. Reliable-Signal Terminology and Semantics</h3>
<p class="docText">We need to define some of the terms used throughout our discussion of signals. First, a signal is <span class="docEmphasis">generated</span> for a process (or sent to a process) when the event that causes the signal occurs. The event could be a hardware exception (e.g., divide by 0), a software condition (e.g., an <tt>alarm</tt> timer expiring), a terminal-generated signal, or a call to the <tt>kill</tt> function. When the signal is generated, the kernel usually sets a flag of some form in the process table.</P>
<p class="docText">We say that a signal is <span class="docEmphasis">delivered</span> to a process when the action for a signal is taken. During the time between the generation of a signal and its delivery, the signal is said to be <span class="docEmphasis">pending</span>.</P>
<p class="docText">A process has the option of <span class="docEmphasis">blocking</span> the delivery of a signal. If a signal that is blocked is generated for a process, and if the action for that signal is either the default <a name="idd1e73640"></a><a name="idd1e73643"></a><a name="idd1e73648"></a><a name="idd1e73653"></a><a name="idd1e73658"></a><a name="idd1e73661"></a><a name="idd1e73664"></a><a name="idd1e73669"></a><a name="idd1e73674"></a><a name="idd1e73679"></a><a name="idd1e73684"></a>action or to catch the signal, then the signal remains pending for the process until the process either (a) unblocks the signal or (b) changes the action to ignore the signal. The system determines what to do with a blocked signal when the signal is delivered, not when it's generated. This allows the process to change the action for the signal before it's delivered. The <tt>sigpending</tt> function (<a class="docLink" href="ch10lev1sec13.html#ch10lev1sec13">Section 10.13</a>) can be called by a process to determine which signals are blocked and pending.</p>
<p class="docText">What happens if a blocked signal is generated more than once before the process unblocks the signal? POSIX.1 allows the system to deliver the signal either once or more than once. If the system delivers the signal more than once, we say that the signals are queued. Most UNIX systems, however, do <span class="docEmphasis">not</span> queue signals unless they support the real-time extensions to POSIX.1. Instead, the UNIX kernel simply delivers the signal once.</P>
<blockquote>
<p class="docText">The manual pages for SVR2 claimed that the <tt>SIGCLD</tt> signal was queued while the process was executing its <tt>SIGCLD</tt> signal handler. Although this might have been true on a conceptual level, the actual implementation was different. Instead, the signal was regenerated by the kernel as we described in <a class="docLink" href="ch10lev1sec7.html#ch10lev1sec7">Section 10.7</a>. In SVR3, the manual was changed to indicate that the <tt>SIGCLD</tt> signal was ignored while the process was executing its signal handler for <tt>SIGCLD</tt>. The SVR4 manual removed any mention of what happens to <tt>SIGCLD</tt> signals that are generated while a process is executing its <tt>SIGCLD</tt> signal handler.</P>
<p class="docText">The SVR4 <tt>sigaction</tt>(2) manual page in AT&amp;T [<a class="docLink" href="bib01.html#biblio01_011">1990e</a>] claims that the <tt>SA_SIGINFO</tt> flag (<a class="docLink" href="ch10lev1sec14.html#ch10fig16">Figure 10.16</a>) causes signals to be reliably queued. This is wrong. Apparently, this feature was partially implemented within the kernel, but it is not enabled in SVR4. Curiously, the SVID doesn't make the same claims of reliable queuing.</P>
</blockquote>
<p class="docText">What happens if more than one signal is ready to be delivered to a process? POSIX.1 does not specify the order in which the signals are delivered to the process. The Rationale for POSIX.1 does suggest, however, that signals related to the current state of the process be delivered before other signals. (<tt>SIGSEGV</tt> is one such signal.)</p>
<p class="docText">Each process has a <span class="docEmphasis">signal mask</span> that defines the set of signals currently blocked from delivery to that process. We can think of this mask as having one bit for each possible signal. If the bit is on for a given signal, that signal is currently blocked. A process can examine and change its current signal mask by calling <tt>sigprocmask</tt>, which we describe in <a class="docLink" href="ch10lev1sec12.html#ch10lev1sec12">Section 10.12</a>.</P>
<p class="docText">Since it is possible for the number of signals to exceed the number of bits in an integer, POSIX.1 defines a data type, called <tt>sigset_t</tt>, that holds a <span class="docEmphasis">signal set</span>. The signal mask, for example, is stored in one of these signal sets. We describe five functions that operate on signal sets in <a class="docLink" href="ch10lev1sec11.html#ch10lev1sec11">Section 10.11</a>.</P>

<UL></ul></TD></tr></table>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/team.gif" width="60" height="17" border="0" align="absmiddle"  alt="Team BBL"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href=ch10lev1sec7.html><img src="images/prev.gif" width="60" height="17" border="0" align="absmiddle" alt="Previous Page"></a>
<a href=ch10lev1sec9.html><img src="images/next.gif" width="60" height="17" border="0" align="absmiddle" alt="Next Page"></a>
</div></td></tr></table>
</body></html><br>
<table width="100%" cellspacing="0" cellpadding="0"
style="margin-top: 0pt; border-collapse: collapse;"> 
<tr> <td align="right" style="background-color=white; border-top: 1px solid gray;"> 
<a href="http://www.zipghost.com/" target="_blank" style="font-family: Tahoma, Verdana;
 font-size: 11px; text-decoration: none;">The CHM file was converted to HTM by Trial version of <b>ChmD<!--209-->ecompiler</b>.</a>
</TD>
</TR><tr>
<td align="right" style="background-color=white; "> 
<a href="http://www.etextwizard.com/download/cd/cdsetup.exe" target="_blank" style="font-family: Tahoma, Verdana;
 font-size: 11px; text-decoration: none;">Download <b>ChmDec<!--209-->ompiler</b> at: http://www.zipghost.com</a>
</TD></tr></table>
